Practically Relevant Quality Criteria for Requirements Documents

This paper presents common weaknesses of requirements documents from commercial software projects that frequently cause problems in practice. Many documents contain extensive, unstructured or even superfluous descriptions of details. At the same time, they lack a thorough description of the aim of the software system or one of its features. Such documents are difficult to read and to work with and they unnecessarily restrict possible solutions. We argue that two quality criteria must be considered in addition to common criteria. First, requirements documents should be based on a sound refinement of the main goals to concrete requirements. Secondly, they should follow the principle of minimality, i.e., no more details than necessary. In order to gain improvements in projects in practice, quality criteria must be communicated to authors. For this purpose, we propose two visualizations, which describe the information structure of the document in a technology-free and domain-independent manner.